The present invention relates to the field of networked applications, and more particularly to user authentication for networked applications.
Authentication and authorization are two basic computer security concepts. In general, authentication refers to verifying the identity of a user attempting to gain access to a computing resource or system, and authorization refers to granting an authenticated user permission to access the resource or system, at least to a degree. There are many methods and protocols for performing authentication, each with various advantages and disadvantages. For example, authentication may be performed using cleartext password methods, hashed password methods, challenge-response methods, or any of many other types of methods.
One common denominator of authentication methods is that they require the user to provide some type of information or perform some action. For example, a user may be required to provide a password, provide biological data such as a retinal scan, provide personal data such as a handwriting sample, provide a number computed based on a synchronized clock in the user""s possession, etc. Of course, what then occurs with the provided information varies for different authentication protocols. For example, the user""s password may be sent to the system in encrypted form, the user""s password may be used as a variable in a mathematical function to compute a value which is then sent to the system, etc.
One major problem which users face is that as they attempt to interact with multiple systems or multiple resources within a system, they are often required to provide authentication information multiple times. This imposes practical problems to users, such as having to remember or store multiple passwords, having to have a synchronized clock currently in their possession, etc., as well as the frustrating workflow problems of being interrupted to type in a password, etc. A concept known as xe2x80x9csingle sign-onxe2x80x9d aims to address these types of problems. The idea behind single sign-on is that a user is authenticated once, in response to providing information or performing an action as described above, and then further authentication procedures are performed transparently to the user as he attempts to access other systems or resources.
The issue of authentication may, of course, be considered at many different levels. For example, authentication may be considered at a system level, such as when a system such as a Windows NT or Unix system verifies that a user attempting to logon has a valid user account and has provided a valid password. Authentication may also be considered at a system resource level. For example, an application which a user attempts to launch may authenticate the user, or an application may authenticate the user when he attempts to open a particular file, etc. In the case of application-level authentication, the application may utilize a protocol or method of its own, and/or authentication data of its own, to perform the authentication process, or the application may rely on system-level authentication services or protocols for authenticating the user.
Most efforts to enable single sign-on have approached the problem by attempting to incorporate system-level authentication services or protocols into the computing environments in question. Kerberos is one well-known example of this type of approach. In the Kerberos approach, a user provides authentication information to a Kerberos server. In response, the Kerberos server grants the user a ticket-granting ticket. The user may then present this ticket-granting ticket to a ticket-granting server in order to get a server ticket. This server ticket may then be used to access resources such as applications. Other attempts to enable single sign-on by building it into the system level include IBM Corporation""s KryptoKnight and Axent Technologies Inc.""s Enterprise Resource Manager.
Such approaches to single sign-on generally aim to provide a comprehensive, very secure authentication infrastructure able to provide system-wide authentication services for applications and other resources. While this may seem ideal, there are several disadvantages involved. For example, in order to introduce this type of single sign-on capability to an existing system, the system may have to be modified significantly. For example, the Kerberos approach may require the Kerberos server, the ticket-granting server, etc. to be set up. Additionally, user machines may need to be modified with special client-side software for the system""s authentication protocol. Once the necessary modifications have been made to a system, there is the problem of how to define the authentication logic for the system. For example, many systems comprise multiple servers in different locations. System administrators must decide which of these servers the single sign-on policy applies to, which users the policy applies to, etc.
Assuming that the system""s single sign-on policy can be adequately defined and supported by the authentication infrastructure, and that any necessary modifications can be made to applications and other resources in order to take advantage of the authentication services, the problem of system interoperability remains. For example, if a user of the system attempts to access an application on a separate system, the user may need to be authenticated again, even if the separate system has single sign-on capabilities of its own.
Focusing now on networked applications, such as web-based applications or other Internet or Intranet applications, the problems described above are magnified. Many networked applications require users to be authenticated, e.g. by entering a username and password on a login screen. As networked applications become increasingly interconnected, it becomes more desirable to enable single sign-on capabilities for them. For example, it may be desirable to enable a user of a web-based application to launch a second application, e.g., by clicking on a hypertext link, and have the second application launch immediately, bypassing an interactive authentication process that the user may normally have to perform when launching the second application.
Single sign-on approaches such as the ones described above may be unsuitable for integrating networked application authentication processes. For example, a developer of a networked application may wish to enable single sign-on to a large number of other networked applications, each of which may run on different systems. It may be impossible or infeasible to make the types of modifications described above to each system. Assuming this obstacle can be surmounted, other obstacles may remain, such as installing any necessary client software on each user""s machine, defining the access rights of users who connect to a system via a network connection, etc. If a networked application were ported to a new system or a new server within a system, various steps in this process may have to be repeated.
What is needed instead is a specialized application-level method enabling single sign-on integration for networked applications. Such a single sign-on method would preferably be managed at the application level, would be independent of any particular computing platform or system-level authentication services, would be based on currently available, inexpensive technology standards in widespread use, and would require minimal modifications to current computer systems.
The present invention is directed toward single sign-on authentication for networked applications. Methods are described for enabling single sign-on both for applications that run in a single Internet domain and for applications implemented by multiple vendors which run in separate Internet domains. A system for integrating Internet-based applications via an application shell is described. In one embodiment, the application shell integrates healthcare-related applications.
In response to a user utilizing a client program to access a master server and provide the master server with information identifying the user, the master server returns code usable by the client program for running the application shell. The client program preferably comprises a web browser application or an application with web-browsing functionality, and the code returned by the master server preferably comprises standard elements interpretable by web browsers, such as markup language code, scripting code, etc. The application shell may be operable to intercept user attempts to launch an application from the application shell environment and may in response determine invocation parameters to send to the application, which the application can use to automatically authenticate the user.
In the preferred embodiment, the master server environment enables organization administrators to create user categories appropriate for their organizations and assign users affiliated with their organizations to these user categories. The user categories may correspond to job titles. For example, an administrator associated with a particular hospital may create user categories such as xe2x80x9cNursexe2x80x9d, xe2x80x9cPhysicianxe2x80x9d, etc. and may assign nurses, physicians, etc. associated with the hospital to their appropriate user categories. Organization administrators may also associate a particular set of healthcare applications with each user category, so that when each user logs on to the master server environment and receives the application shell code, the code is tailored to implement an application shell integrating an appropriate set of healthcare applications for the particular user.
In one embodiment, in addition to enabling single sign-on integration, the application shell also enables other types of application integration, such as context sharing integration and user interface integration. In the preferred embodiment, little or no modification to the applications themselves is necessary in order to achieve the application shell integration.
Administrators of the master server environment may provide application administrators with an administrative tool for configuring the master server environment with information necessary to achieve the single sign-on integration, such as application invocation parameters. One embodiment of an administrative tool and its interface to the master server environment is described below.